PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 3/USEnet 3.063

Text File | 1988-04-08 | 32.9 KB | 782 lines | [TEXT/ttxt]

29-Sep-87 09:45:32-PDT,34418;000000000001
Date: Fri 28 Aug 87 21:22:02-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V3 #63

Usenet Mac Digest     Friday, August 28, 1987        Volume 3 : Issue 63

Today's Topics:
     DiskTimer III Proposal - Comments?
     Re: Mac <-> VMEbus ??
     Hypercard Reports
     Re: MPW and MultiFinder
     Re: Hard Disks
     Macintosh XL, SCSI, and hard disk drives.
     Re: Which Is Better: DMCS or Concertware+?
     Comments on SuperMac 19" Trinitron monitor system (longish)
     Re: MPW and MultiFinder
     Mac File Representation
     Remote file representation

----------------------------------------------------------------------

From: [e-mail] (ephraim)
Subject: DiskTimer III Proposal - Comments?
Date: 25 Aug 87 14:56:27 GMT
Organization: Wang Laboratories, Lowell, MA, USA

I am discussing with Steve Brecher the creation of a new version of
DiskTimer (DT III) to avoid or reduce certain problems with DiskTimer
II's measurements of disk performance.  At his suggestion, I'm taking
the discussion public with this request for comments.  Please mail
responses to decvax!masscomp!wang7!ephraim (if you can), MASSTECH on MCI
mail (if that's easier for you), or Ephraim Vishniac / P.O. Box 1357 /
East Arlington, MA 02174 if e-mail just doesn't do it for you. Please
understand that DiskTimer III is intended to be in the same general vein
as DiskTimer II.  That is, it will be a non-destructive test of a disk
drive's data transfer rate measured at the driver interface.  It will
not be a test of system performance, so correlation with a user's
expectation of performance will continue to be problematic.

---------Start of technical stuff-----------

DiskTimer II attempts to measure the data transfer rate of a disk drive
under optimal conditions, i.e., with a minimum of head and cylinder
crossings.  To do so, it makes elaborate efforts to locate a region of
the disk which presents the least data transfer time, then makes
repeated measurents of read/write times in that region.

There are (at least) two failings in this approach.  First, this optimal
case is not typical.  Files are not placed with respect to tracks or
cylinders, so their boundaries will often be crossed in the course of a
single I/O operation. Of course, if DiskTimer tested a single region
without the precautions that it now takes, drives which happened to seek
in that region would be unfairly penalized.

Second, this approach fails completely to measure data transfer time
when the driver incorporates a local cache.  Since the same region is
read and written repeatedly, DiskTimer II presents an optimal caching
situation.  This is the cause of the ridiculous results that one vendor
was touting in sales literature at the Boston MacWorld show.

The major feature of DiskTimer III is a change in approach that avoids
both of the above problems.  Rather than read/write the same area 100
times, DT III will read/write consecutive areas of the disk.  So, track
and cylinder crossings will be represented in their native proportions.
With respect to caching, the test will be pessimal instead of optimal.
Since the test is for raw data transfer rate, this is exactly as it
should be.

To be more precise about the test sequence, DT III will:

    read CurrentTestSector - 1 into TrashBuffer
    dither-with-respect-to-system-tick-and-disk-rotation
    start ReadTimer
    read 24K at CurrentTestSector into DataBuffer
    stop ReadTimer
    read CurrentTestSector - 1 into TrashBuffer
    dither-with-respect-to-system-tick-and-disk-rotation
    start WriteTimer
    write 24K at CurrentTestSector from DataBuffer
    stop WriteTimer
    advance CurrentTestSector by 24K/SectorSize for a total of 100 reads
and 100 writes.  Of course, there will be tests to avoid running off the
end of the volume, to stop on I/O errors, etc.  The same general idea
will be used on the Seek portion of the benchmark, to insure that the
drive really does seek instead of returning cached data.

Minor new features of DiskTimer III will include:
    reporting the disk driver's name, icon, and 'where' string
    reporting the system version, ROM version, and CPU type
    user selection of the volume to test
    if SCSI drive, report Vendor ID and Product ID from SCSI Inquiry

Since DiskTimer III results will not be directly comparable to DT II
results, there will be a new scale.

So: What problems am I introducing? What other problems should I
address?

-----------End of technical stuff----------

-- Ephraim Vishniac
masscomp!wang7!ephraim

------------------------------

From: [e-mail] (taylor)
Subject: Re: Mac <-> VMEbus ??
Date: 25 Aug 87 12:56:37 GMT
Organization: CERN European Organization for Nuclear Research

CERN has developed VMEbus interfaces for the complete Macintosh family.
The system is called MacVEE (Microcomputer Applied to the Control of VME
Electronic Equipment), and it provides direct memory-mapped access to
single or multi-crate VMEbus or CAMAC systems from the Macintosh,
Macintosh Enhanced, Macintosh Plus or Macintosh SE.

The MacVEE interface for Macintosh II (MICRON - MacVEE Interface Card
Resident On NuBus) is currently being polished for production and should
be available 4Q/87.  It is compatible with the same VMEbus master module
and CAMAC crate controller as the earlier systems.  Installation is
easier, because MICRON simply plugs into a NuBus slot in Mac II.

The development of MICRON is supported by C. Rubbia and is being carried
out with the assistance of the UA1 experiment collaboration, comprising
members from CERN EF, EP and DD Divisions.

The latest version of the MacVEE User Manual is available to
professional researchers from:

B.G. Taylor
EP Division
CERN (European Organization for Nuclear Research)
CH-1211 Geneva 23
Switzerland

BITNET:  bgt.wb@gen
ARPANET: [e-mail]          (while it lasts...)

------------------------------

From: [e-mail] (walter jeffries)
Subject: Hypercard Reports
Date: 24 Aug 87 14:05:33 GMT
Organization: Dartmouth College, Hanover, NH

Has anyone figured out how to print non-standard reports in HyperCard?

I want to make a stack that keeps data and then from that data fills out
forms that are larger than the size of a single card.  To do so it would
seem that I need to use a report. Unfortunately the reports seem to be
very constrained as to what and how they will print things out.

Does anyone have any other ways of filling out a standard form?  Or of
using a report so that you can control precisely where things can go?

Thanx in advance...
  -Waltervj@dartvax


------------------------------

From: [e-mail] (Joel West)
Subject: Re: MPW and MultiFinder
Date: 26 Aug 87 14:18:37 GMT
Organization: Palomar Software, Inc., Vista, CA

Actually, there was a very good article about GetNextEvent, etc. on Bix
that will be in Byte.

Since MultiFinder steals the time if it sees two nullEvt's in a row,
it's even possible to work with GetNextEvent-compiled programs, as Tom
Thompson of Byte demonstrated.


------------------------------

From: [e-mail] (Dan Graifer)
Subject: Re: Hard Disks
Date: 26 Aug 87 17:27:40 GMT
Organization: UCSD Office of Academic Computing


About once a month, somebody new asks the net for opinions on hard
disks. The Macintosh magazines do comparative reviews, but they are
always way out of date, and don't always cover the whole market.

I am probably going to be sorry I did this, but I hereby volunteer to
gather some statistics.  Before you hit your (r)espond keys, let's think
about this. I want ONE LINE responses, with STANDARD TAB SEPARATED
FIELDS.  I can then use switcher to paste the responses into my db.  I
would propose the following:

Make
  SuperMac
Model
  DataFrame 20
DriveMake
  NA
Capacity MB
  21
Type
  SIDE (other responses are: UNDER, INTERNAL, OTHER)
Port
  SCSI (OTHER)
DiskTimRead
  98
DiskTimerWrite
  99
DiskTImerAccess
  69
    (My XP upgrade is on order!  I know DiskTimer results can be misleading,
     but it is the only standardized test we have.  I will include a notice
     in any reports that I release)
HardwareReliability
  5 (scale 0-5)
MakerResponsiveness
  4 (scale 0-5)
Software
  SPOOLER (vs NOSPOOLER)
  BACKUP (vs NOBACKUP)
Noise
  2 (0=Silent to 5=banshee)


Thus my response would be

SUPERMAC DATAFRAME 20 NA 21 SIDE SCSI 98 99 69 5 4 SPOOLER BACKUP 2
[ TABS converted to spaces for digest - Jeff ]

Is the potential for lines longer than 80 chars a problem for some
hosts?  Are there important fields I am missing?  Before I ask for
responses, lets hash this out.  Once I post the final format,  I would
want EVERYONE on the net who has a hard disk to send me a response.
Only post if you cannot E-mail with repeated tries!

I may loose net access by the end of this year.  If so, I will mail
somebody else the DB. I hope I am not going to be sorry I did this.
Hopefully, after this has exhausted me in a few months, someone else
will take over the job for a quarter. I expect to get a hundred
responses immediately, and maybe that many again over the next year.
The resulting reports, and maybe even the database could then be posted
here or in the sources group.

PS, Oh, do you think date of purchase should be in the DB?  I don't want
to ask for price, as some may not want to reveal special deals, and
thats subject to change over time anyways.
                              Dan Graifer
                              [e-mail]
Disclaimer: Nobody ever listens to me anyways; Why should they start now?

------------------------------

From: [e-mail] (Benjamin Britt)
Subject: Macintosh XL, SCSI, and hard disk drives.
Date: 26 Aug 87 04:07:15 GMT
Organization: Information Sciences Institute, Univ. of So. California

Is there a SCSI board for the Macintosh XL? It looks simple enough to
have been done but I have had little luck even finding anyone selling
prototyping boards for the XL.  Sun Systems Remarketing has introduced a
20Meg drive but I would rather invest the money in a hard disk drive
that I can later use when I finally, if ever, decide to dump my XL.

On a related note, I notice that the 5 Meg Profile Hard disk uses a
Seagate ST-506 drive- the same hard disk drive interface used in IBM
PCs.  Has anyone tried upgrading the Profile with a 10 or 20 Meg IBM
PCish ST-506?


Ben

--
Benjamin Britt
USC/Information Sciences Institute

------------------------------

From: [e-mail] (H. Moskovitz)
Subject: Re: Which Is Better: DMCS or Concertware+?
Date: 26 Aug 87 22:01:25 GMT
Organization: The Second Door on the Right

In article <[e-mail]> [e-mail] (Alan Perry) writes:
>

>I like best, it is Studio Session by MacNifty.  The instruments are digitized

I have two questions:

    1) Does it support MIDI (if so, how well)?

    2) How well does it print out scores on the LW? Does it support
       ADOBE's Sonata font (like DMCS)?


-- -----------------------------------------------------------
        Howard Moskovitz
    AT&T Bell Labs @ Liberty Corner, NJ
        ihnp4!io!howard


------------------------------

From: [e-mail] (Julian Vrieslander)
Subject: Comments on SuperMac 19" Trinitron monitor system (longish)
Date: 27 Aug 87 04:13:24 GMT
Organization: Cornell Theory Center, Cornell University, Ithaca NY

Well, I recently installed a Mac II system, and I thought that some of
you might be interested in hearing a bit about the 19" SuperMac monitor,
since this is the new version with the Sony Trinitron tube.

First, some history for those who tuned in late.  SuperMac first
introduced a color video adaptor card and 19" color monitor at the time
of, or shortly after, the Mac II rollout.  They still sell that monitor,
and it uses a tube made by Ikegami.  At the Boston Expo they introduced
new 19" and 16" Sony Trinitron color monitors.  The suggested retail
price for the 19" Sony is $700 more than the 19" Ikegami's, but most
people think the Trinitron is sharper than the Ikegami.  The SuperMac
Spectrum video card works with all of their color tubes.

Now for my mini-review.  First of all, be sure to measure your desk if
you are thinking of buying one: this thing is *large* (21" from screen
to rear panel). There are four plastic feet on the bottom, so a stand is
optional.  We chose the tilt-swivel base, which raises the screen about
2 to 3".  This base is designed to sit on a desk top, and the resultant
screen height is just about right (for me anyway).  I wouldn't put the
monitor on top of the Mac II: the thing weighs about a hundred pounds.
If you really want the monitor over the Mac, SuperMac will sell you a
beefy three legged stand that straddles the system box (the Mac can be
pulled out at the front for changing cards, etc.).

The monitor seems well made and ergonomically sensible.  All user
controls (horizontal and vertical convergence, contrast, vertical
centering, on/off) are in front, below the screen.  The Trinitron
monitor does not have have a degaussing button (like the Ikegami's), so
it probably has automatic degaussing.
 One curious note: the screen is advertised as 768 pixels high by 1024
wide. But, at least for my sample, the actual pixel size is 768 by 1016.
 This width was verified (on both my system and my dealer's demo system)
by the Mousometer DA and by some test code I wrote as a doublecheck.
Where's the missing rowByte?

The Spectrum video adaptor card did not come with a slot shield (a metal
stamping to seal the opening at the back of the system box against RFI
emission), but SuperMac Tech Support has promised to mail one to me.
SuperMac's advertisements claim that the board can be programmed for 1,
2, 4 or 8 bits/pixel, but the boards shipping now do *not* work in 2 or
4 bit mode.  Tech Support says that a retrofix will be available.
Currently the board does not have GenLock capability, but they claim
that this will be provided, possibly as an extra-cost plug-in.

Image quality is very impressive.  Convergence can be adjusted to within
about one pixel's worth of misalignment from corner to corner.  Nine
point text is not as clear as on the 9" screens of the little Macs, but
still very readable.  The screen has an effective anti-reflection
coating that enhances contrast.  If I were to pick nits about the
picture quality, there would be two things to mention.  There are 2
*very* fine horizontal lines that run horizontally across the screen at
the 1/3 and 2/3 heights.  These lines, I am told, are seen on many
Trinitrons and are a consequence of the tube's internal construction.
More noticable to me is a slight variation in screen brightness when
rendering the medium gray of the desktop.  This appears in faint
vertical bands, like interference fringes with 2 mm periodicity.  A
techie at SuperMac told me that the effect is present in all units and
can be eliminated by choosing another desktop pattern.  Perhaps it is a
Moire interaction between the medium gray pattern and the shadowmask.

Documentation is adequate, but unimpressive.  The installation
instructions appear to be written for the Ikegami, and are still
labelled as a beta draft, at that.  There is also a sheet supplied by
Sony, with a brief description of the monitor's controls, and
connections.  I had no trouble getting the system to work, but a less
technically oriented user might get confused by the mismatch between the
hardware and the doco.

At the Boston Mac Expo, PCPC (the folks who make the MacBottom hard
disks) were also introducing a 19" color monitor system for the Mac II.
Their systems ship with monitors from either Mitsubishi or Sony (the
same 19" that SuperMac uses), but they were claiming that their video
card was superior to SuperMac's.  This superiority was alleged to be due
to a cleaner design with lower parts count, lower power dissipation, and
less RFI emission, resulting in better reliability and a visably better
picture.  Note, however, that their board runs *only* in 8 bits/pixel
mode.  I could not see an obvious difference in picture quality between
the PCPC and SuperMac systems demoed at the show, but I would be
interested in hearing reports from others who have experience with both
products.


--
Julian Vrieslander    [phone]
Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853
UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj
ARPA: [e-mail]     BITNET: eacj@CRNLTHRY

------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: MPW and MultiFinder
Date: 26 Aug 87 21:14:06 GMT
Organization: Advanced Technology Group, Apple Computer

In article <[e-mail]> [e-mail] (Doug Moen)
writes:
>
>1) Will MPW (Macintosh Programmers Workshop) be compatible with MultiFinder?

MPW 2.0 is Multifinder aware; not only does it work with Multifinder,
but it takes vantage of the Multifinder environment.

For example, if you are running Multifinder and launch an application
from MPW, the MPW shell does not run its normal suspend script.  It
simply uses sublaunching to have Multifinder run the application in a
separate area of memory (exactly as if you had launched the app from the
Finder).  Since MPW does not exit, there is no reason to save the state
of variables, aliases, etc.

>2) Will the necessary calls to GetNextEvent (or whatever) be inserted
>   into the MPW C compiler so that it can run as a background task under
>   MultiFinder?

This was not done for MPW 2.0, so you can't run the compilers in the
background under Multifinder.

--
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: [e-mail]

------------------------------

[ The following messages were taken from the INFO-APPLETALK mailing list.
- Jeff ]

From: voder!apple!andrews
Subject: Mac File Representation
Date: 22 Aug 87 22:36:51 GMT
Organization: Apple Computer Inc., Cupertino, USA

Here is our first attempt at a proposal for representing Mac files on
other file systems.  Please circulate it freely.  I welcome comments and
suggestions, with the following caveat:

PLEASE KEEP YOUR COMMENTS BRIEF AND CONCISE.  I EXPECT A LOT OF FEEDBACK
AND I CAN'T POSSIBLY WADE THROUGH A WHOLE LOT OF MATERIAL. I CANNOT
REPLY TO EVERYONE PERSONALLY.

Please send useful comments and suggestions directly to me.  Look to
this bulletin board for further drafts.

--------------------------------------------------------------------

AppleSingle and AppleDouble formats for file representation

A Draft Proposal from Apple Computer, Inc.

21 August, 1987

Apple Computer is proposing two standards for representing Macintosh
files on non-Macintosh file systems, with the goal of preserving all
attributes characteristic of Macintosh files (Finder info, icons,
comments) on file systems that do not support such attributes ("foriegn"
file systems).  Experience seemed to indicate that a single format could
not be devised that would be adequate for all cases, but that with two
closely-related formats most needs could be served.  A secondary goal in
designing these formats was to make them general enough so that they
could be used to represent a file from any file system on any other file
system.

Note that this is a draft and is subject to change.

The two formats are called AppleSingle and AppleDouble.  In AppleSingle
format, all contents and attributes of a Macintosh file are kept in a
single file on the foriegn file system.  Both forks, Finder info, icons,
etc. are arranged in a single file with a simple structure.  This format
is intended to be used primarily as a storage format; i.e., for those
cases in which the Macintosh file must be stored on a foriegn file
system and later reconstructed into a true Macintosh file.

For those applications in which the users of the foriegn file system
wish to access and perhaps modify the contents of the Macintosh file,
AppleDouble format would be more appropriate.  Since most Macintosh
applications keep the file "data" in the data fork, AppleDouble format
saves the contents of the data fork in a separate foriegn file.  All
other file attributes are kept in another file.

Specifically, Apple's proposal does not rule out the possibility of
building applications that wish to access and modify MacSingle-format
files.  Nor does it preclude using AppleDouble format for simple storage
of Macintosh files.  We merely present them as alternatives.

The only assumption we have made is that each file system on which these
file formats will be supported allows the creation of a simple file; an
uninterpreted stream of bytes.  We have ruled out designing a format
that relied on the creation of subdirectories, since some file systems
do not support them.

Before getting into the discussion of the formats, some terms will be
defined.  The term home file system will be used to mean the file system
for which the file's contents were created.  A Unix application could
create an AppleSingle file that holds a resource and data fork in which
is contained a MacWrite-formatted document.  The home file system for
such a file will be Macintosh Hierarchical File System (HFS).  In most
cases, where a file is created and used on the same file system, the
home file system will be that system.  An AppleSingle or AppleDouble
file is usually another representation of the file's contents on a
foriegn file system.

AppleSingle

An AppleSingle file contains a header followed by data.  The header is
composed of several fixed fields and a list of entry descriptors, each
pointing to an "entry".  Standard entries that Apple will define
include:  Data Fork, Resource Fork, Real Name (name in the home file
system), Comment, Icon, File Info, etc.  Each entry would be optional
and may or may not appear in the file.

   Header:             Magic Number      (4 bytes)
                       Version Number    (2 bytes)
                       Home File System  (4 bytes, ASCII encoded)
                       Number of entries (2 bytes)
                   /   Entry ID          (2 bytes)
   for each entry: |   Offset            (4 bytes)
                   \   Length            (4 bytes)

The "Magic Number" field is modeled after the feature in Unix.  It is
intended to be used in whatever way each foriegn file system desires to
distinguish this file as one in AppleSingle format.  The Magic Number
for AppleSingle format is $00051600 or 0x00051600.

The "Version Number" field is used to denote the version of AppleSingle
format in case the format evolves (perhaps more fields would be added to
the header).  The version described here is version $0001 or 0x1.

The "Home File System" is explained above.  For Macintosh files, the
value of this field is 'mac ' or $6D616320 or 6D616320.  Others are
shown below:

     Macintosh    'mac ' or $6D616320 or 0x6D616320
     ProDOS       'pdos' or $70646F73 or 0x70646F73
     MS-DOS       'mdos' or $6D646F73 or 0x6D646F73.
     Unix         'unix' or $756E6978 or 0x756E6978.

We welcome suggestions for other file systems that should be included in
this list.

The "Number of entries" field tells how many different entries are
included in the file.  It is an unsigned 16-bit number, and may be zero.
If non-zero, then that number of entry descriptors will immediately
follow this field.

For each entry, the entry descriptor indicates just what the entry is,
where the entry is located in the file, and how big the entry is.  Apple
will define a set of Entry IDs and their values:

     Data Fork      1 (standard Mac Data Fork)
     Resource Fork  2 (standard Mac Resource Fork)
     Real Name      3 (the file's name in the home file system)
     Comment        4 (standard Mac comment)
     Icon, B&W      5 (standard Mac Black & White Icon)
     Icon, Color    6 (standard Mac color icon)
     File Info      7 (file information)
     Dates          8 (Create, Modification, and Backup dates)

Apple reserves the range of Entry IDs from 0 to 32767 ($7FFF or 0x7FFF)
for future use.  Apple will not arbitrate the use of the rest of the
range; these values can be used by other systems to define their own
types of entries.

The File Info entry will be different for each home file system.  For
Macintosh HFS, the entry is 32 bytes long and consists of the standard
Finder Info and Extended Finder Info fields.  [To be defined:  formats
for MS-DOS, Unix, and ProDOS, etc.]

Icon entries will probably not appear in most files since they are
typically stored as a bundle in the application file's resource fork.

The actual data representing the entry must be in a single contiguous
block.  It is pointed to by the offset field, which is an unsigned
32-bit number indicating the byte offset from the start of the file to
the start of the entry.  The entry length is also an unsigned 32-bit
number representing the length in bytes.  The length may be zero.

After some number of entry descriptors, the actual entry data would
appear.  The entries could appear in any order, but since the data fork
is the entry that would be most commonly extended, Apple strongly
recommends that the data fork entry always be kept last in the file to
facilitate its extension.

It is possible to have holes in the file (unused space between entries).
To find where the holes are, one must take the list of entry
descriptors and sort them into increasing offset order.  If the offset
field of an entry is greater that the offset plus length of the previous
entry, then a hole exists between the entries.  This may be used to
one's advantage; for example:  if a file's comment is 10 bytes long, one
could create a hole of 190 bytes after the comment field to easily allow
for the comment to later expand to its maximum length of 200 bytes.
Because an AppleSingle file may contain holes, every entry must be found
by getting its offset from its entry descriptor - not by assuming that
it begins after the previous entry.

Byte ordering in the file will follow 68xxx convention.  This is
somewhat of a religious issue, but it was decided that picking one
format was better than adding a flag to the file to indicate which
ordering was being used, so that applications wouldn't have to have code
to handle both cases.

AppleDouble

AppleDouble format is now easily described:  it is the same as
AppleSingle format except that the data fork is kept in a separate
foriegn file.  The file containing the data fork will be called the
AppleDouble Data File, and the other file will be called the AppleDouble
Header File.

The AppleDouble Data File consists of just the standard Macintosh Data
Fork with no extra header at all.  The AppleDouble Header File has
exactly the same format as the AppleSingle file, except that it does not
contain a data fork entry.  The Magic Number of an AppleDouble Header
File differs from that of an AppleSingle file so that applications can
tell whether or not they need to look elsewhere for the data fork.  The
Magic Number for AppleDouble format is $00051607 or 0x00051607.

The entries in the Header File could appear in any order, but since the
resource fork (in this case) is the entry that would be most commonly
extended, Apple strongly recommends that the resource fork entry always
be kept last in the file to facilitate its extension.  The data fork is
easily extended since it resides by itself in the Data File.

If it is possible on the foriegn file system, one could create a new
type of entry that "pointed" to the AppleDouble Data File to make it
easy to find.

-----------------------

AppleSingle format specifically will not include an algorithm for
generating the AppleSingle file name from the "real" Macintosh name.
This was done because the foriegn file systems of interest differ quite
a bit in the area of file name syntax, and since the  file's real name
can be kept as an entry within the AppleSingle file.

The same is true for AppleDouble Data File names, yet we would like to
propose a standard for deriving the AppleDouble Header File name from
the AppleDouble Data File name.  Again, due to differing file name
syntax, a standard per foriegn file system is proposed.  For example:

   On Unix systems, take the file's real name and by character
   substitution, deletion, or truncation, derive an AppleDouble
   Data File name that is at least one character less than the
   maximum file name length.  The AppleDouble Header File name
   will be the same as the AppleDouble Data File name with a
   preceding percent sign '%'.

   On ProDOS systems, take the file's real name and by character
   substitution, deletion, or truncation, derive an AppleDouble
   Data File name that is at least two characters less than the
   maximum file name length.  The AppleDouble Header File name
   will be the same as the AppleDouble Data File name with a
   preceding 'R.' (ASCII-R, period).

   On MS-DOS systems, take the file's real name and by character
   substitution, deletion, or truncation, derive a name that is
   at most eight characters long.  The AppleDouble Header File
   name will be the derived name plus an extension of '.ADF'
   (AppleDouble File).  The AppleDouble Data File name will be
   the derived name plus whatever extension is most appropriate
   in the MS-DOS world.  If the data fork is pure text (CR, LF)
   the the Data File extension would be '.TXT'.  If the data fork
   conformed to some other standard MS-DOS file format, it would
   be given the appropriate extension.  This would have to be
   decided by whatever application created the AppleDouble files.

And so on.  AppleDouble name derivations, to coin a term, would be
defined for all the file systems of interest.  This would allow
applications running on the foriegn file system (and human users as
well) to easily see which files are AppleDouble pairs.  Knowledgeable
users, if they know the derivation, could even rename the files in such
a way so as to preserve the connection between the two.  There is no way
to prevent one file of the pair from being inconsistently renamed, moved
or deleted.

------------------------------

From: palomar!joel%beowulf
Subject: Remote file representation
Date: Mon, 24 Aug 87 17:04:31 pdt

First, I'd like to thank Apple for sharing this before it's set in
stone.  There are many Mac programmers who are on USENET,  (and also
Delphi and Bix, which receive edited copies of USENET news) who can
participate.

The spec seems well thought-out, but I have a few suggestions:

1. Home File System should include:
    'vms ' or $766D7320
    'os2 ' or $6F734220
   I'm not sure if 'unix' should be treated as a monolithic
   whole, as the syntax of file names, at least, differs significantly
   from System V (14 chars max) to BSD.

2. The AppleDouble format does not address one important issue.
   The data fork of a Macintosh file is not normally readable
   by another file system.  To contrast it with three with
   which I am familiar:
    *) Mac: CR at end of each record
    A) UNIX: LF at end of each record
    B) MS-DOS: CR-LF at end of each record
    C) VMS: preceeded by a binary length
   If the data fork is to be readable, then it must be translated
   into the native format, and its original format saved.

   I think there needs to be a line-translation entry to indicate
   the original line delimiter so it can be restored from the
   native format
    Record Delim 9  1 or more delimiter characters
   For example, a Mac file stored on MS-DOS would be stored with CR-LF
   delimiters but with Record Delim = $0D.  (on VMS, you could use
   RAT=CR, which would be an exact copy of the Mac data fork).

   The AFP or some other protocol also needs either record-
   at-a-time i/o or a "What is this file's delimiter" query, so
   that a Mac program can read a file directly from a UNIX
   server (in LF-delimited form) and vice versa.

3. The use of the icon ought to be better defined, or this will
   vary all over the place.  For example, the spec ought to say
   something like:
    Applications normally include their icons, but documents
    do not.
   (or maybe all always include their icon)

4. Again, their ought to be file naming guidelines for mapping
   (recommendations for consistency, not absolute rules) so that
   there is similarity between various systems.  For example,
     A) Case is stripped on systems that don't support case, so
    Foo.C becomes FOO.C
     B)    Spaces are mapped to "_" if available, otherwise to
    another available non-alphanumeric special character.
     C)    Standard mappings for Macintosh extended characters.
    For example, all accented letters are stripped to their
    IUMagString equivalents,
        `e becomes e
        c, becomes c
    etc.  Characters that have no equivalent are removed
    ((R), TM, (C), etc.) since they are likely to be noise
    characters.

5. Presumably if a new file is being created in this directory
   and it truncates to an existing AppleSingle or AppleDouble
   file, the program will check for the actual name and, if
   different, choose a new truncated name to save the file.

   For example,

    'AntiDisestablish Text' and 'AntiDisestablish Text 2'
   might be stored as
    ANTIDIST. and ANTIDIS2.
   on an MS-DOS system.

This is obviously an area where a standard is sorely needed, and as an
A/UX user, I hope A/UX 1.0 implements the final  AppleDouble proposal.

    Joel West
    Palomar Software, Inc., POB 2635, Vista, CA  92083
    [e-mail]
    ihnp4!crash!palomar!joel    [e-mail]
    AppleLink: D0619            MCI: Palomar

------------------------------

End of Usenet Mac Digest
************************
-------